In a live broadcast or teleconference, streaming whereby data with real-time characteristics such as video or speech is transmitted continuously is performed on a one-to-many (live broadcast) or many-to-many (teleconference) basis.
The following are known as distribution methods for performing streaming to a plurality of receiving terminals in a network such as the Internet or an intranet in a company or school: (1) a method in which a plurality of one-to-one unicast communications are used, (2) a method in which an IP multicast is used, (3) a method in which an XCAST is used.
With (1) a method in which a plurality of one-to-one unicast communications are used, a transmitting terminal transmits a packet to a plurality of receiving terminals, and therefore the transmitting terminal load becomes high and the load on a network channel near the transmitting terminal is heightened.
With (2) a method in which an IP multicast is used, a packet transmitted by a transmitting terminal is duplicated and transferred to a plurality of receiving terminals by a router that is a relay apparatus in the network. Consequently, the transmitting terminal load does not become high and the load on a network channel near the transmitting terminal is not heightened. However, an IP multicast packet cannot pass through a router that can only handle a unicast. In order to use an IP multicast, all the routers in a network must support an IP multicast, and therefore it is necessary to install IP multicast compatible routers in the network.
(3) Non-Patent Document 1 discloses an XCAST. With a method in which an XCAST is used, an XCAST packet transmitted by a transmitting terminal is duplicated and transmitted by an XCAST-compatible router in the same way as in an IP multicast. Also, an XCAST packet is transferred to one destination to which distribution has not been performed in the same way as a unicast packet even by an XCAST-incompatible router. All destination addresses to which reception is to be performed are listed in an XCAST packet. A destination to which distribution has not been performed is entered in an XCAST packet. A receiving terminal transmits an XCAST packet to a destination to which distribution has not been performed. When an XCAST that operates in this way is used, the transmitting terminal load does not become high, and neither is the load on a network channel near the transmitting terminal heightened. However, with this method it is necessary to list all destination addresses in a packet, making it unsuitable for a case in which there are many receiving terminals.
Thus, when performing streaming to a plurality of receiving terminals, streaming to the plurality of receiving terminals can be implemented using (1) a method in which a plurality of one-to-one unicast communications are used, (2) a method in which an IP multicast is used, or (3) a method in which an XCAST is used.
When conflict with a packet of another communication or the like occurs in a network, a packet being transmitted may be lost. A method of compensating for a packet loss is to retransmit the same packet from the transmitting terminal. Here, retransmission means that a receiving terminal detecting a packet loss transmits a retransmission request for the lost packet to the transmitting terminal. The transmitting terminal retransmits a packet corresponding to the received transmission request to the receiving terminal. The receiving terminal receives the retransmitted packet and compensates for the lost packet.
However, if this retransmission processing is performed when streaming is performed to a plurality of receiving terminals, a plurality of receiving terminals simultaneously transmit a retransmission request and retransmission requests are concentrated in the transmitting terminal, and therefore the transmitting terminal load becomes high and the load on a network channel near the transmitting terminal is heightened.
With the technology described in Patent Document 1, in order to resolve this problem, when an information distribution apparatus located upstream of a receiving terminal receives a retransmission request, it broadcasts to a receiving terminal information for suppressing transmission of a retransmission request from another receiving terminal. If a receiving terminal receives this information before the timing at which it is to transmit a retransmission request is reached, it does not transmit a retransmission request.
Through this kind of operation, retransmission request transmissions from a plurality of receiving terminals are suppressed, and therefore the transmitting terminal load is not heightened and the load on a network channel near the transmitting terminal is not heightened. However, this method cannot be employed in a network in which broadcast communication cannot be used.
Also, with streaming, real-time characteristics are important. That is to say, it is necessary for a receiving terminal to play back received video, speech, or suchlike data within a fixed time period.
Patent Document 2 proposes a method whereby, when a plurality of receiving terminals perform retransmission in concert, retransmission request transmission timing is calculated that takes account of a streaming playback time in order to perform operation that mutually suppresses retransmission requests.
That is to say, when streaming, retransmission requesting, and retransmission are performed using an IP multicast, a lost packet retransmission request need not necessarily be transmitted to a transmitting terminal. That is, by transmitting a retransmission request by means of an IP multicast, a retransmission request can be transmitted to another receiving terminal, and another receiving terminal can perform retransmission. At this time, a receiving terminal delays retransmission request transmission timing by a random time period. A receiving terminal that receives from another receiving terminal a response to a retransmission request transmitted by means of an IP multicast at earlier timing does not transmit the same retransmission request. Through this kind of operation, retransmission request transmissions are suppressed as a whole, and therefore a problem of retransmission requests from a plurality of receiving terminals being concentrated in the transmitting terminal does not arise.
Thus, Patent Document 2 proposes a method whereby, with respect to the above method, the time period by which retransmission request transmission timing is delayed is adjusted taking the playback time into consideration. By using the method of Patent Document 2, the probability of a problem of a retransmission packet not being in time for the playback time arising can be reduced by having all receiving terminals delay the retransmission request transmission timing by a long time period. However, these methods presuppose an IP multicast, and cannot be employed in a network in which an IP multicast cannot be used.
On the other hand, Non-patent Document 2 discloses TFRC (TCP Friendly Rate Control) as a method of estimating an available band between a transmitting terminal and receiving terminal. With TFRC, an available band is estimated from a Round Trip Time (RTT) and loss event rate between a transmitting terminal and receiving terminal. In streaming, if data is transmitted in accordance with an available band calculated by TFRC, communication in which the probability of a packet being lost is reduced becomes possible. However, if retransmission is applied to streaming whereby data is transmitted using TFRC, a band is consumed by transmitting retransmission requests and retransmission packets. There is thus a problem of the probability of a packet being lost increasing. This probability is further increased when streaming is performed to a plurality of receiving terminals. It is also possible to make retransmission requests to a plurality of receiving terminals while making provision for retransmission request and retransmission packet losses. In this case, however, there is a problem of the load on a network channel near a receiving terminal being heightened due to a concentration of retransmission requests, and of retransmission requests being lost.    Patent Document 1: Japanese Patent Application Laid-Open No. 2002-124935    Patent Document 2: Japanese Patent Application Laid-Open No. 2003-209576    Non-patent Document 1: Y. Imai, M. Shin and Y. Kim, “XCAST6: eXplict Multicast on IPv6”, IEEE/IPSJ SAINT2003 Workshop 4, IPv6 and Applications, Orland, January 2003    Non-patent Document 2: M. Handley et al., “TCP Friendly Rate Control (TFRC) : Protocol Specification”, RFC 3448, Internet <URL:http://www.faqs.org/rfcs/rfc3448.html>